前言

在上一篇文章中，我整理了HIS、EMR與EHR的差異。

其中，EHR強調病人長期且可能跨越不同醫療機構的健康紀錄。既然現在大部分資料都已經電子化，看到這裡可能會產生一個疑問：

A醫院把病歷檔案傳給B醫院，不就完成資料交換了嗎？

實際上，「把資料傳出去」只是第一步。

即使B醫院成功收到資料，也不代表B醫院的系統能夠正確讀取、理解及使用。不同醫院的資訊系統可能由不同廠商開發，採用不同的資料庫、欄位名稱、代碼及交換格式。

今天就來看看，不同醫院的資料為什麼不能直接互通。

收到資料，不等於看得懂資料

假設A醫院要將病人王小明的資料傳給B醫院。

A醫院傳送了以下內容：

P001,王小明,M,20000101,HTN

人類或許可以猜測這些資料分別代表：

• P001：病人編號
• 王小明：姓名
• M：男性
• 20000101：出生日期
• HTN：高血壓

但是，B醫院的電腦不一定知道每一個值代表什麼。

如果雙方事前沒有約定資料結構，B醫院可能無法確定：

• 每個欄位的順序
• M代表男性還是其他狀態
• 日期使用哪一種格式
• HTN是院內代碼還是標準疾病代碼
• P001是病歷號、身分證號還是其他編號

因此，資料交換不能只要求「傳得過去」，還要讓接收資料的系統知道資料代表的意義。

障礙一：資料格式不同

醫療資料可能使用許多不同的格式保存，例如：

• 純文字
• CSV
• Excel
• XML
• JSON
• PDF
• 圖片
• 資料庫表格
• 特定醫療資訊交換格式

假設A醫院使用CSV傳送資料：

patient_id,name,gender,birth_date
P001,王小明,M,2000/01/01

B醫院則使用JSON：

{
  "id": "P001",
  "name": "王小明",
  "gender": "male",
  "birthDate": "2000-01-01"
}

兩份資料在人類眼中表達的內容很接近，但對電腦而言，它們是兩種不同的結構。

如果B醫院的程式只會處理JSON，就不能直接將CSV當成JSON讀取，必須先經過格式轉換。

即使雙方都使用JSON，也不能保證一定能交換，因為裡面的欄位名稱和資料結構仍然可能不同。

障礙二：欄位名稱不同

假設兩家醫院都使用JSON記錄病人姓名。

A醫院可能這樣表示：

{
  "patient_name": "王小明"
}

B醫院可能這樣表示：

{
  "name": "王小明"
}

C醫院則把姓氏和名字分開：

{
  "family_name": "王",
  "given_name": "小明"
}

這三份資料都在表達病人姓名，但欄位名稱及結構不同。

對人類來說，看一眼就能理解；可是電腦必須依照事先寫好的規則處理。如果系統只認得name，收到patient_name時就可能不知道該把它放在哪裡。

其他資料也可能遇到類似問題，例如：

如果沒有共同規則，就必須為每一組系統另外建立欄位對應關係。

障礙三：相同欄位使用不同表示方式

即使欄位名稱完全相同，欄位內容也可能採用不同表示方式。

性別表示方式不同

A醫院：

{
  "gender": "M"
}

B醫院：

{
  "gender": "male"
}

C醫院：

{
  "gender": "1"
}

如果沒有另外提供代碼說明，就無法確定1代表男性、女性或其他分類。

日期格式不同

同一個日期可能寫成：

2000/01/02

02/01/2000

2000-01-02

其中02/01/2000甚至可能被解讀成1月2日，也可能被解讀成2月1日。

布林值表示方式不同

「是」與「否」可能使用：

• true與false
• Y與N
• 1與0
• 是與否

如果雙方沒有共同定義，系統就可能做出錯誤判斷。

障礙四：醫療代碼不同

醫療資訊中有許多內容不能只用一般文字表示，例如：

• 疾病診斷
• 檢驗項目
• 藥物
• 手術及處置
• 醫療專業
• 檢查部位

假設A醫院以「高血壓」記錄診斷，B醫院寫成「Hypertension」，C醫院則使用內部代碼D001。

雖然它們可能代表相同疾病，但如果沒有共同的標準代碼，電腦不一定知道這三種寫法具有相同意義。

醫療領域因此會使用各種標準化術語或代碼系統，例如：

• ICD：疾病分類
• LOINC：檢驗及臨床觀察項目
• SNOMED CT：臨床醫療術語
• 各國或機構使用的藥品代碼

如果系統使用院內自訂代碼，資料傳到其他機構時，還需要將院內代碼對應到雙方都能理解的標準代碼。

障礙五：測量單位不同

醫療資料不只有數值，還必須知道數值所使用的單位。

例如：

{
  "test": "體溫",
  "value": 37
}

這筆資料中的37代表攝氏37度，還是華氏37度？

如果缺少單位，數值就可能失去意義。

體重也可能使用公斤或磅，血糖則可能因地區及系統不同而使用不同單位。若系統只交換數字，卻沒有一起交換測量單位，接收方就可能做出錯誤解讀。

較完整的資料應同時表示數值及單位，例如：

{
  "test": "體溫",
  "value": 37,
  "unit": "°C"
}

不過，即使加入文字單位，仍然需要統一的代碼和規則，才能讓電腦可靠地進行判讀及換算。

障礙六：無法確認是不是同一位病人

不同醫院通常有自己的病歷號。

王小明在A醫院的病歷號可能是：

A123456

在B醫院則可能是：

B987654

兩個病歷號不同，但實際上是同一個人。

反過來說，也可能有兩位病人剛好姓名和生日相同。系統不能只看到「王小明」就直接認定是同一位病人。

跨系統交換資料時，需要考慮如何正確比對病人，例如綜合使用：

• 姓名
• 出生日期
• 身分識別資料
• 聯絡方式
• 地址
• 病歷號
• 其他識別資訊

在多個病人資料庫之間，也可能使用MPI，也就是Master Patient Index，協助管理及比對病人身分。

病人比對非常重要。如果把甲病人的檢驗結果放到乙病人的病歷中，可能影響後續的醫療判斷與病人安全。

障礙七：資料內容不完整

即使資料格式正確，也可能因為缺少必要欄位而無法使用。

例如，收到一筆檢驗結果：

{
  "test": "血糖",
  "value": 95
}

這筆資料仍然有很多問題：

• 沒有病人資訊。
• 沒有檢驗日期。
• 沒有測量單位。
• 不知道是空腹血糖還是飯後血糖。
• 不知道檢驗結果是否已經完成審核。
• 不知道由哪個機構產生。

如果每一家醫院對必要欄位的認定不同，即使資料成功傳送，也可能因為資訊不足而無法直接使用。

因此，醫療資料標準除了定義欄位名稱，也可能需要規定哪些欄位必須出現、可以出現幾次，以及應該使用什麼代碼。

障礙八：系統與版本不同

醫院資訊系統可能在不同年代建置，也可能來自不同廠商。

有些系統使用較新的Web API，有些則使用較早期的資料交換方式；有些系統持續更新，有些系統因為與院內設備或既有流程緊密連結，不容易立刻更換。

即使兩家醫院都聲稱支援同一項標準，也可能使用不同版本，或對規範採取不同的實作方式。

因此，資料交換前仍然需要確認：

• 使用哪一個標準
• 使用哪一個版本
• 支援哪些資料類型
• 哪些欄位為必填
• 使用哪些代碼系統
• 支援哪些查詢及交換功能

障礙九：隱私、權限與資訊安全

醫療資料包含病人的身分、疾病、用藥、檢驗及就醫紀錄，屬於高度敏感的資訊。

即使技術上可以交換，也不能因此任意傳送。

系統還需要確認：

• 是誰要求取得資料？
• 對方是否具有合法權限？
• 病人是否需要同意？
• 可以取得哪些範圍的資料？
• 資料傳輸時是否受到保護？
• 系統是否留下查詢及操作紀錄？
• 資料是否傳送給正確的機構？

所以醫療資料交換除了技術問題，也涉及法規、組織政策、權限管理及資訊安全。

「可以傳」和「可以合法、安全地傳」是兩件不同的事情。

什麼是互通性？

互通性英文稱為：

Interoperability

依照HealthIT.gov對醫療資訊互通性的說明，它不只代表系統能夠交換電子健康資訊，也包含接收方能夠使用從其他系統取得的資訊。

換句話說，醫療資訊互通性至少要做到：

1. 資料傳得出去
2. 對方收得到
3. 對方看得懂
4. 對方能正確使用
5. 交換過程安全且符合規範

例如，A醫院成功把一份PDF檢驗報告傳給B醫院，B醫院的醫師也能開啟閱讀。這已經完成某種程度的資訊交換。

但是，如果B醫院的系統無法辨認PDF中的檢驗項目及數值，就無法自動將結果加入趨勢圖，也無法進一步進行資料分析。

因此，「人可以閱讀」與「電腦可以結構化處理」的程度並不相同。

標準化如何幫助資料互通？

如果不同醫院各自決定資料格式，可能需要為每一組系統建立專用的轉換程式。

假設有三家醫院：

• A醫院要和B醫院建立轉換規則。
• A醫院要和C醫院建立另一套規則。
• B醫院和C醫院也要建立自己的規則。

當參與交換的系統越多，需要維護的介面也可能越來越複雜。

如果大家採用共同的標準，就能針對相同的資料結構、欄位及代碼進行開發，降低每次交換都要重新定義規則的情況。

不過，標準並不代表所有醫院的內部系統都必須完全相同，而是讓它們在交換資料時，能夠使用一套共同理解的方式。

FHIR如何協助解決問題？

FHIR將不同類型的醫療資料定義成Resource，並規定各Resource的資料結構。

例如，FHIR Patient Resource可以使用類似以下的方式表示病人資料：

{
  "resourceType": "Patient",
  "id": "patient-001",
  "name": [
    {
      "family": "王",
      "given": ["小明"]
    }
  ],
  "gender": "male",
  "birthDate": "2000-01-02"
}

在這段資料中：

• resourceType表示資料類型是Patient。
• id表示這筆Resource的識別碼。
• name使用固定結構表示姓名。
• gender依照規範使用指定代碼。
• birthDate使用統一的日期格式。

FHIR也能搭配標準術語、Resource之間的Reference，以及RESTful API交換資料。

不過，FHIR不是只要安裝後就能自動解決所有問題。醫療機構仍然需要處理病人比對、院內欄位轉換、標準代碼對應、權限驗證，以及在地法規和工作流程等問題。

今日小結

今天整理了不同醫院資料無法直接互通的常見原因，包括：

• 資料格式不同
• 欄位名稱不同
• 表示方式不同
• 醫療代碼不同
• 測量單位不同
• 病人識別方式不同
• 資料內容不完整
• 系統及版本不同
• 隱私、權限與資訊安全限制

我原本可能會把資料交換理解成單純的「傳送檔案」，但實際上，真正的互通還包含接收、理解及使用資料。

為了讓不同醫療系統使用共同的方式溝通，醫療資訊領域發展出了各種資料交換標準。

在認識FHIR之前，下一篇要先回到它的重要基礎——HL7，看看醫療資料交換標準如何一路發展到FHIR。

明日預告

Day 5｜從HL7到FHIR：醫療資料交換標準的演變

參考資料

1. HealthIT.gov：Interoperability
   https://healthit.gov/interoperability/

2. HealthIT.gov：About Health Information Exchange
   https://healthit.gov/health-it-basics/hie/

3. HL7 FHIR R4：FHIR Overview for Developers
   https://hl7.org/fhir/R4/overview-dev.html

4. HL7 FHIR R4：Patient Resource
   https://hl7.org/fhir/R4/patient.html